In recent years, the Internet has become one of the most important tools for organizations to communicate and interact with each other. For security reasons, a user in a particular organization often has to be authenticated before being granted access to resources in another organization. Different mechanisms have been developed to facilitate user authentication. One such mechanism is Web Services (WS)-Federation. WS-Federation enables the sharing of identity across enterprise boundaries using Extensible Markup Language (XML) security tokens. These XML tokens utilize formats, such as Security Assertion Markup Language (SAML) or Extensible Rights Markup Language (XrML), and contain rich authorization claims in addition to identity data. For example, under WS-Federation, a security token associated with an account may assert not just the account's identity (e.g. in the form of an email address) but also date of birth, group affiliations, or the like.
Typically, the claims in the security tokens flow between a pair of enterprises. The originator of the tokens is called the Identity Provider. The Identity Provider owns a user's identity and authentication. The consumer of the tokens is called the Resource Provider. The Resource Provider may provide any number of Web Services or other applications. A cryptographic trust may be established between the two parties (for example, the Identity Provider shares his X509 certificate with the Resource Provider) so that the Resource Provider can authenticate the Identity Provider as the authority for security tokens.
In WS-Federation, the Identity Provider typically deploys a server that hosts a Security Token Service (STS). An Identity Provider's STS is generally referred to as STS-IP. The STS-IP authenticates users based on legacy credentials (e.g. username and password) and issues a WS-Federation security token, which will be accepted by the Resource Provider.
Under WS-Federation, it is possible for web services or other applications to have explicit trust with each partner's STS-IP. However, in order to simplify the administration of trust, the Resource Provider generally deploys its own STS, which may be referred to as STS-RP. Individual applications typically trust the STS-RP and a single trust generally exists between STS-RP and STS-IP, which embodies the business level agreement between the two parties. In this manner, each application may be ignorant of the many different Identity Providers.
Although WS-Federation is an effective way to establish trust between two systems, the relationships may become difficult to manage when the systems increase in complexity. Specifically, if a Resource Provider deploys multiple applications, these applications may not all expect security claims in the same format. For example, one application may expect the user's date of birth while another may expect the user's age. Similarly, difficulties may arise if each partner Identity Provider provides claims in different incompatible formats. For this reason, it is often necessary for the STS-RP to perform transformation from the claim format of an Identity Provider to the claim format required by an application.
A system in WS-Federation may be configured to handle account stores and transformations that are anticipated when the system was first created. However, it is often difficult for an existing system to be reconfigured to add new types of account stores or to add customized claim transformations.
An effective solution for providing extensibility to systems in WS-Federation without undue complexity continues to elude those skilled in the art.
Like reference numerals are used to designate like parts in the accompanying drawings.